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PREFACE  AND  OVERVIEW 


This  Note  covers  an  element  of  the  Arroyo  Center  project  entitled  the  Alternative 
Army  Airframes  Analysis;  also  referred  to  as  the  LHX  study.  The  study  objective  was  to 
recommend  to  the  Army  an  acquisition  strategy  for  the  development  of  an  Army  aircraft  that 
can  best  meet  the  Army’s  tactical  aviation  requirement,  given  the  current  state-of-the- 
art  of  the  various  technologies  and  their  ability  to  perform  the  various  missions.  Final  study 
results  and  conclusions  were  briefed  to  representatives  of  the  U.S.  Army  and  OSD  on 
November  10, 1987. 

This  project  was  sponsored  jointly  by  the  Honorable  Richard  Godwin,  Under 
Secretary  of  Defense  for  Acquisition,  and  the  Honorable  James  Ambrose,  Under  Secretary 
of  the  Army.  It  was  conducted  within  the  Force  Development  and  Employment  Program  of 
the  Arroyo  Center  and  coordinated  with  a  parallel  study  by  the  Institute  for  Defense 
Analyses  (IDA). 

Other  Notes  and  Reports  documenting  component  analyses  of  the  study  arc: 

R-3625-A,  Design,  Performance,  and  Cost  of  Alternative  LHX  Configurations,  G.  K.  Smith, 

G.  Acker,  J.  H.  Bigelow,  D.  Dreyluss,  S.  Laforge,  R.  Pei,  S.  Resetar,  and  R.  Petruschell 
(Competition  Sensitive),  November  1988. 

R-3623-A,  The  Army  Alternative  Airframes  Analysis:  Overview  Report  (U),  S.  Drczner,  B. 
Rostker,  E.  Gritton,  G.  Smith,  and  M.  Callero  (Secret/Competition  Sensitive).  To  be 
published. 

R-3621-A,  Engineering  Survivability  Analysis  of  LHX  Aircraft  Alternatives  (U),  E.  Gritton, 

H.  Bailey,  C.  Crain,  L.  Mundie,  H.  Ory  (S/CSI/NOFORN/WN).  To  be  published. 

R-3617-A,  LHX  Helicopter  and  Tilt  Rotor  Flight  Simulator  Experiment,  C.  T.  Veit,  M. 
Callero,  and  B.  J.  Rose.  To  be  published. 

R-3616-A,  Small  Unit  Operational  Performance  of  LHX  Variants  (U),  M.  Callero,  J. 
Bondanella,  D.  Norton,  and  A.  Zobrist  (Secret).  To  be  published. 

N-2725-A,  LHX  Communication  Issues  (U),  E.  Cesar,  H.  Ory,  and  M.  Schaffer  (Secret).  To 
be  published. 

N-2724-A,  LHX  Armament  (U),  M.  Schaffer  and  W.  Benson  (Secret).  To  be  published. 

N-2721-A,  LHX  Mission  Equipment  Package  Tradeoffs,  M.  Schaffer  and  H.  Ory 
(Competition  Sensitive).  To  be  published. 
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N-2720-A,  Reactive  Threat  to  LHX  (U),  J.  Hiland,  L.  Mundie,  and  C.  Crain  (Secret).  To  be 
published. 

N-2719-A,  Automatic  Target  Recognition  for  LHX,  H.  Bailey,  H.  Ory,  and  M.  Schaffer, 
January  1989. 

N-2718-A,  Reducing  Risks  Associated  with  Developing  the  LHX  Mission  Equipment 
Package,  M.  Berman,  D.  Mclver,  B.  Orvis,  M.  Robbins,  and  R.  Ruth,  January  1989. 

N-2708-A,  Pilot  Workload  Reduction  and  Mission  Equipment  Package  Utilization  for  LHX, 
D.  Hartley.  To  be  published. 

THE  ARROYO  CENTER 

The  Arroyo  Center  is  the  U.S.  Army’s  Federally  Funded  Research  and  Development 
Center  for  studies  and  analysis  operated  by  The  RAND  Corporation.  The  Arroyo  Center 
provides  the  Army  with  objective,  independent  analytic  research  on  major  policy  and 
management  concerns,  emphasizing  mid-  to  long-term  problems.  Its  research  is  carried  out 
in  five  programs:  Policy  and  Strategy;  Force  Development  and  Employment;  Readiness  and 
Sustainability;  Manpower,  Training,  and  Performance;  and  Applied  Technology. 

Army  Regulation  5-21  contains  basic  policy  for  the  conduct  of  the  Arroyo  Center. 

The  Army  provides  continuing  guidance  and  oversight  through  the  Arroyo  Center  Policy 
Committee,  which  is  co-chaired  by  the  Vice  Chief  of  Staff  and  by  the  Assistant  Secretary 
for  Research,  Development,  and  Acquisition.  Arroyo  Center  work  is  performed  under 
contract  MDA903-86-C-0059. 

The  Arroyo  Center  is  housed  in  RANK’S  Army  Research  Division.  The  RAND 

Corporation  is  a  private,  nonprofit  institutk.  ihat  conducts  analytic  research  on  a  wide  range 

of  public  policy  matters  affecting  the  nation’s  security  and  welfare. 

Stephen  M.  Drezner  is  Vice  President  for  the  Army  Research  Division  and  Director 

of  the  Arroyo  Center.  Those  interested  in  further  information  concerning  the  Arroyo  Center 

should  contact  his  office  directly: 

Stephen  M.  Drezner 
The  RAND  Corporation 
1700  Main  Street 
P.O.  Box  2138 

Santa  Monica,  California  90406-2138 


Telephone:  (213)393-0411 
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THE  ARMY  ALTERNATIVE  AIRFRAMES  ANALYSIS: 

OVERVIEW  OF  MAJOR  FINDINGS  AND  POLICY 
RECOMMENDATIONS1 

The  Army  Alternative  Airframes  Study,  also  known  as  the  LHX  study,  set  out  to 
assess  the  capabilities  of  various  aircraft  alternatives  to  perform  the  Army’s  aerial  attack  and 
scout  missions.  Although  airframes  based  on  more  advanced  technologies  were  considered, 
the  study  focused  primarily  on  three  generic  alternatives:  an  advanced >  onventional 
helicopter,  a  tilt  rotor,  and  an  upgraded  Apache. 

Our  primary  recommendation  Is  that  the  Army  develop  and  procure  a  new 
advanced  conventional  helicopter  rather  than  a  tactical  tilt  rotor  or  an  Apache  upgraded 
to  meet  the  LHX  requirements.  This  choice  is  supported  by  all  aspects  of  our  study:  the 
engineering  and  flight  simulator  analyses:  the  cost  analyses;  the  force-on-force  analyses  of 
unit-  and  theater-level  operational  performance;  and  the  analyses  of  factors  beyond  cost  and 
performance. 

However,  we  conclude  that  the  Army’s  emphasis  should  not  be  on  lightness  per  se, 
but  on  the  features  that  will  be  incorporated  into  a  new  “Advanced  Helicopter  System.” 
Based  upon  our  analysis,  we  have  concluded  that  a  new  helicopter  weighing  about  12,000  lb 
will  be  necessary  to  fully  accomplish  the  SCAT  missions  designed  for  the  LHX. 
Furthermore,  we  found  that  lower  weight  is  not  a  very  good  surrogate  for  lower  cost  or 
higher  survivability.  To  design  a  truly  light  helicopter — on  the  order  of  10,000  lb — requires 
giving  up  mission-essential  functions  with  little  cost  savings.  For  example,  a  13  percent 
savings  in  weight  from  the  12,000  lb  helicopter  translates  into  only  a  3  percent  savings  in 
total  incremental  life  cycle  costs.  Rather  than  on  weight,  the  design  focus  should  be  on 
mission  performance,  survivability,  cost  (l.e.,  force  size  for  a  fixed  budget),  and 
robustness. 

We  refer  to  this  new  aircraft  as  a  “helicopter  system”  to  emphasize  how  greatly  its 
cost-effectiveness  depends  on  highly  advanced  subsystems,  in  particular  the  Mission 
Equipment  Package  (MEP)  and,  secondarily,  the  armament.  This  observation  is  important 
regardless  of  which  airframe  the  Army  selects  for  the  LHX  SCAT  role. 

The  successful  development  of  the  MEP  is  critical  to  achieving  the  program’s 
planned  performance  and  cost  goals.  In  particular,  the  reliability  and  maintainability  (R&M) 
of  the  MEP  will  heavily  influence  LHX  O&S  costs.  Currently  the  Army  expects  the  LHX 

•This  is  a  summary  of  the  major  findings  and  policy  recommendations  of  the  Army 
Alternative  Airframes  Analysis  as  a  whole;  it  is  provided  here  as  a  context  for  the  technical 
description  of  the  software  system  SUN  Terrain  Procedures  provided  in  this  Note. 
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to  experience  SO  percent  fewer  removals  than  the  Apache,  a  reduction  that,  if  achievable, 
would  result  in  a  projected  $6  billion  savings  in  spares  and  manpower  over  the  life  cycle  of 
the  helicopter.  However,  the  MEP  involves  a  significant  technological  advance,  and  the 
associated  technical  risk  must  be  carefully  managed.  Fortunately,  the  Army  is  in  a  position 
to  capitalize  on  Air  Force  and  RAND  experience  with  advanced  avionics.  This  experience 
demonstrates  that  integrated  digital  subsystems  have  complex  failure  modes  which  require 
time  to  understand  in  the  operational  environment.  Once  they  are  understood,  it  is  within  the 
state-of-the-art  to  write  the  appropriate  software  for  fault  isolation  and  detection. 

The  Army  can  realize  Its  goals  for  MEP  performance  and  supportabllity  by 
carefully  maturing  the  subsystem  through  development  and  early  fielding.  The 
approach  involves  the  intensive,  phased  collection  of  detailed  engineering  data  and  includes 
special  R&M-related  testing  during  development.  The  maturation  process  requires  data 
from  about  25,000  flying  hours,  based  on  the  helicopter’s  performance  in  its  actual  operating 
and  maintenance  environments.  While  the  MEP’s  R&M  is  being  matured,  special  support 
structures  may  be  needed  to  boost  performance.  This  approach  implies  a  low  rate  early 
production  to  avoid  the  high  cost  of  retrofitting  a  large  portion  of  the  force.  We  estimate  the 
total  cost  of  such  a  program  to  be  $120  to  370  million — a  small  price  to  pay  for  the  projected 
savings. 

The  armament  currently  planned  for  the  Advanced  Helicopter  System  (AHS)  will 
likely  require  upgrading  early  in  the  aircraft’s  field  life.  The  AHS  should  have  the  potential 
to  cany  fire-and-forget  missiles;  in  addition  to  the  Airborne  Adverse  Weather  Weapons 
System  (AAWWS),  we  suggest  a  Combined  Aims  Multipurpose  Missile  System 
(CAMMS)  that  has  capability  against  both  ground  armor  and  remasked  helicopters. 

Finally,  the  AHS  must  be  robust  enough  to  play  In  the  counter/countermeasure 
game  that  will  begin  as  it  enters  the  field.  We  recommend  that  study  of  potential  reactive 
threats  should  begin  now. 

Our  analyses  of  unit-level  operational  performance  indicate  that  reduced  radar 
signatures  are  less  important  than  we  had  expected,  at  least  in  the  close-in  battle.  A 
robustness  in  this  area  is  still  required  for  several  reasons,  including  the  ability  of  the  threat 
to  adapt  The  Army  should  begin  with  as  ’’clean”  a  design  as  possible,  and  the  design 
philosophy  for  the  AHS  should  include  a  strategy  to  incorporate  passive  signature  reduction 
measures  initially  since  including  them  later  in  the  life  of  the  system  would  be  much  more 
difficult. 


In  addition,  we  recommend  that  the  Army  Improve  the  survivability  of  the 
Apache  through  a  reduced  signature  prototype  program.  Greater  survivability  would 
increase  the  Apache’s  mission  performance  and  flexibility.  If  the  program  demonstrates  the 
feasibility  and  utility  of  reducing  the  Apache’s  signature,  and  the  Army  decides  to  retrofit 
accordingly,  it  should  also  reassess  the  planned  mix  of  LHX  (l.e.,  AHS)  and  Apache. 

We  should  note,  however,  that  for  the  LHX  role  itself  we  prefer  a  new  advanced 
conventional  helicopter  over  even  an  upgraded  Apache  with  reduced  signature.  A  new 
helicopter  will  leave  the  Army  better  positioned  to  evolve  its  tactical  aviation  forces  after  the 
year  2000. 

We  further  recommend  that  the  Army  should  develop  an  austere  prototype  of 
an  operational  configured  tilt  rotor  to  validate  technical  performance  and  to  enable 
development  of  employment  tactics  that  would  exploit  the  special  characteristics  of 
that  design.  Our  analyses  confirm  the  tilt  rotor’s  advantages  in  speed  and  range  and  reveal 
some  intriguing  maneuverability  capabilities.  Our  analyses  did  not  show  that  the  speed 
provides  significant  overall  operational  advantages.  It  might  permit  a  modest  increase  in 
sortie  production  and  appears  to  increase  survivability  for  certain  missions.  Prototypes  will 
enable  the  Army  to  explore  the  tilt  rotor’s  suitability  for  specialized  missions  (such  as  air- 
to-air  and  troop  insertion),  leaving  this  option  open  for  the  future. 

Finally,  we  believe  that  the  decision  concerning  a  new  utility  helicopter  can  wait. 
Either  the  tilt  rotor  or  the  AHS  could  spin  off  a  utility  version.  The  choice  of  utility 
helicopter,  therefore,  should  not  be  a  factor  in  the  LHX  SCAT  decision. 


The  need  to  evaluate  Army  attack  helicopters  in  a  mission  context  which  allows 
slight  differences  in  physical  characteristics  to  be  measured  in  terms  of  capability  and 
mission  effectiveness  motivated  the  development  of  software  called  the  SUN  Terrain 
Procedures  (STP).  This  new  modelling  and  analysis  system  fills  a  niche  within  a  hierarchy 
of  models  used  to  analyze  various  levels  of  engineering  accuracy  and  simulation  detail. 
Engineering  studies  use  high  accuracy  to  compare  helicopters  in  single  maneuvers  (e.g.,  a 
turn  or  climb)  or  in  a  short  sequence  of  maneuvers.  The  mission  context  adds  important 
variables  such  as  spatial  distribution  of  defenses,  terrain,  and  targets.  However,  these 
mission  studies  must  meet  with  acceptance  and  understanding  through  the  use  of  standard 
simulators  such  as  the  JANUS  system.  The  ability  to  bridge  the  gap  between  these  two 
approaches  with  a  locally  developed  system  was  made  possible  by  the  availability  of  a 
number  of  technical  elements  within  the  RAND  Military  Operations  Simulation  Facility^ 
(MOSF).  These  elements  include: 

1 .  Powerful  32-bit  microcomputers  (SUN  and  VAX) 

2.  Large  memories  (4  to  16  megabyte) 

3.  Capable  graphics  for  image  and  vector  data 

4.  The  JANUS  system  (colocated  with  MOSF) 

5.  Geographic  data  supporting  the  study  areas 

6.  A  geographic  information  system  to  prepare  geographic  data 

7.  Terrain  elevation  processing  including  line-of-sight  calculation 

8.  Image  processing  capability  to  process  terrain  data 

9.  HELCOM  flight  capability  data  in  computer  table  form  supplied  by  the  LHX 
project 

10.  An  engineering  analysis  system 

The  STP  allow  the  analyst  to  graphically  define  and  evaluate  a  flight  path  over  a 
geographical  area,  taking  into  consideration  the  geographical  area’s  terrain  and  cultural 
features,  locations  of  enemy  sensors  and  air  defense  systems,  line  of  sight,  and  flight  time 
characteristics  associated  with  each  air  defense  system,  determining  probabilities  of  kill  and 
circular  area  probabilities  along  the  “visible”  regions  of  the  aircraft’s  flight  path. 


The  three  phases  of  STP  operation  are:  (1)  preparation  of  geographic  data  sets,  (2) 
interactive  graphics  for  flight  path  entry,  and  (3)  analysis  of  the  path.  This  Note  begins  with 
a  system  description  and  then  describes  the  three  phases  in  order.  An  appendix  shows  in 
greater  detail  how  the  interactive  graphics  are  used. 
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I.  INTRODUCTION 


The  Army  community  has  benefitted  greatly  from  the  use  of  high-resolution  graphics- 
based  systems  such  as  JANUS  for  military  simulation  and  analysis.  First  developed  at 
Lawrence  Livermore  Laboratory  to  analyze  tactical  nuclear  weapons,  JANUS  has  been 
extensively  modified  at  the  Army’s  TRAC  facility  at  White  Sands  Missile  Range  for  a  much 
wider  range  of  situations.  The  Arroyo  Center  at  RAND  has  created  an  active  JANUS 
laboratory  colocated  with  the  Military  Operations  Simulation  Facility  (MOSF)  and  plans  an 
increasing  use  of  this  facility.  At  the  same  time,  a  small  effort  has  begun  to  create  a  new 
system,  supplementary  to  JANUS,  that  trades  full  battlefield  complexity  for  greater 
increases  in  the  resolution  that  can  be  applied  to  engineering  details.  The  system  is  based  on 
the  latest  available  microprocessor  technology,  including  fast  32-bit  CPUs,  large  memories, 
and  capable  graphics.  Since  the  ability  to  input  terrain  is  a  key  element  of  the  system,  and 
SUN  computers  are  used,  the  system  has  become  known  as  STP,  for  SUN  Terrain 
Procedures. 

The  STP  system  is  designed  to  represent  terrain  data  and  culture  in  graphical  display 
format  for  user-friendly  operator  (pilot)  interaction  and  to  use  an  image  processing  format 
for  greatest  resolution  and  analytic  capabilities.  It  is  capable  of  representing  a  flight  path 
close  to  the  nap  of  the  earth  with  a  resolution  of  about  a  foot  vertically  and  10  to  25  meters 
horizontally  depending  upon  the  study  area  scale.  The  flight  path  is  specified  by  operator 
input  to  a  map-like  graphics  display,  and  the  dynamics  of  the  path  are  calculated  by 
HELCOM  model  routines  (Ref.  1).  Intervisibility  between  the  aircraft  and  defensive  sites 
can  be  accurately  calculated  to  yield  the  space  and  time  windows  during  which  the  aircraft 
is  exposed.  Subsequent  batch  runs  can  analyze  the  effects  of  particular  weapon  types  on  the 
flight  path.  Each  of  these  phases  of  STP  operation  will  be  described  in  the  major  sections  of 
this  Note. 

STP  consists  of  about  65  programs  for  the  manipulation  of  image,  graphics,  and 
tabular  data,  and  an  executive  system  that  creates  a  user-friendly  interface  to  the  library  of 
routines.  STP  can  be  categorized  as  a  geographic  information  system  with  additional 
engineering  analysis  capabilities.  The  main  components  of  STP  include:  (1)  STP  executive, 
(2)  image  processing  routines,  (3)  polygon  file  processing  routines,  (4)  table  processing 
routines,  and  (5)  project-specific  application  routines.  These  components  are  described  in 
the  next  five  subsections. 
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STP  EXECUTIVE 

The  executive  for  STP  is  the  Transportable  Applications  Executive  (TAE) 
developed  by  the  NASA  Goddard  Space  Flight  Center  and  Century  Computing  Inc.  Each 
of  die  65  application  programs  has  a  simple  interface  to  the  TAE  executive  that  defines  the 
parameters  that  a  user  might  want  to  set  when  the  program  is  run.  The  user  is  offered  four 
modes  of  operation. 

1.  A  command  list  naming  the  program  and  the  values  of  named  parameters. 

2.  A  tutor  mode  in  which  a  window  pops  up  with  parameter  names,  descriptions,  help 
options,  default  values,  etc.,  with  command  buttons  for  run,  exit,  or  other  types  of  help. 

3.  A  procedure  mode  that  allows  the  user  to  string  together  any  number  of  commands  into 
a  higher  level  procedure.  Procedures  can  then  be  treated  the  same  as  programs. 

4.  A  menu  mode  that  allows  the  user  to  find  a  program  or  procedure. 

Some  examples  of  TAE  procedures  are  given  in  later  sections.  Because  TAE  is 
available  on  VMS  or  UNIX,  is  written  in  C  language,  and  is  itself  modular,  the  whole 
system  is  portable  and  allows  portability  of  applications.  TAE  facilitates  incremental  growth 
of  the  application  routines,  decreases  maintenance  costs,  provides  system  services,  and 
allows  portability.  TAE  also  comes  with  complete  on-line  documentation,  has  a  complete 
field  history,  and  is  independent  of  discipline,  project,  or  data  type,  hence  it  is  very  reliable. 
TAE  provides  an  excellent  user-friendly  interface  that  insulates  the  user  from  the  host 
operating  system,  provides  a  congenial  and  consistent  environment,  and  has  a  parameter 
prompting  feature.  TAE  provides  long-term  support  with  a  support  office,  phone-in  service, 
a  full  library  of  on-line  and  paper  documentation,  a  newsletter,  and  a  biennial  user’s 
conference. 

IMAGE  PROCESSING  ROUTINES 

An  image  is  a  large  matrix  of  cells  that  can  represent  two-dimensional  spatial  data. 

For  example,  elevation  data  are  represented  by  projecting  an  area  of  the  earth  onto  the 
cellular  matrix  and  placing  the  elevation  of  the  terrain  (as  a  number)  into  each  corresponding 
cell.  Because  these  image  data  sets  are  large,  an  image  processing  system  is  useful  for 
retrieving,  manipulating,  and  displaying  them.  Special  functions  such  as  line-of-sight 
calculation  are  then  added  to  the  menu. 


-3- 


A  standard  image  format  is  defined  that  requires  a  label  giving  image  size,  type,  and 
history.  Supported  types  include  character,  short  integer,  integer,  floating  point,  double 
precision,  and  complex.  The  presence  of  a  label  relieves  the  user  from  having  to  specify  the 
data  size  over  and  over  when  a  long  procedure  is  performed.  Large  image  processing  is 
supported.  Programmers  are  requested  to  allow  for  a  10000  x  10000  image  size  in  all 
programs  except  where  that  size  does  not  make  sense.  The  programs  and  their  functions  are: 

•  IMLOG  -  create  an  image  from  external  data  in  binary  or  character  format 

•  DTEDLOG  -  create  an  image  from  DMA  DTED  (Defense  Mapping  Agency  Digital 
Terrain  Elevation  Data) 

•  IMCOPY  -  copy  all  or  a  subwindow  of  an  image 

•  IMLIST  -  print  part  of  an  image 

•  IMARITH  -  apply  an  arithmetic  function  to  (up  to)  five  images 

•  IMSIZE  -  resample  an  image  to  new  pixel  size 

•  IMFFT  -  compute  two-dimensional  fast  Fourier  transform  of  an  image 

•  IMAPGEN  -  substitute  table  values  in  an  image  (choroplethie  mapper) 

•  IMSHADE  -  compute  shading  for  terrain  data  for  a  color  graphic  display 

•  CONTOUR  -  compute  contours  for  image  terrain  data 

•  FILL  -  fill  polygon  contours  in  an  image 

•  MOSAIC  -  join  adjacent  images  into  a  larger  image 

•  OVERLAY  -  polygon  overlay  in  image  format  (yields  a  table) 

•  GETZVAL  -  read  image  values  at  locations  given  in  a  table 

•  PUTZVAL  -  put  table  values  into  an  image  at  locations  from  the  table 

•  LOS  -  compute  an  image  of  line  of  sight  for  a  terrain  image  (size  limited) 

•  LOSANG  -  compute  an  image  for  angle  of  depression  or  glance  angle  to  terrain 

POLYGON  FILE  PROCESSING  ROUTINES 

Polygon  files  can  contain  points,  lines,  and  area  boundaries  in  short  integer,  integer, 
floating,  or  double  precision  formats.  Short  labels  are  attached  to  all  items  to  aid  user 
processing. 


POLYGEN  -  create  a  polyfile  from  external  data  in  character  format 
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•  GDRLOG  -  create  a  polyfile  from  external  data  in  the  local  graphics  format 

•  TAB2POLY  -  create  a  polyfile  from  data  in  table  format 

•  GDROUT  -  write  polyfile  in  to  the  local  graphics  format 

•  POLY2TAB  -  write  polyfile  to  table  format 

•  POLYLIST  -  print  parts  of  a  polyfile 

•  DFADLOG  -  convert  DMA  DFAD  (Digital  Feature  Area  Data)  to  a  polyfile 

•  METRXLOG  -  convert  digitized  data  from  METREX  INC.  to  a  polyfile 

•  POLYCAT  -  concatenate  two  polyfiles 

•  POLYREG  -  linear  transform  of  a  polyfile  containing  map  data 

•  POLYMAP  -  map  transformation  of  a  polyfile.  This  routine  also  can  be  used  in  an 
interactive  mode  to  make  forward  and  inverse  transformations  on  20  commonly  used  map 
transformations 

•  POLYSEED  -  create  a  file  that  identifies  polygons  in  DMA  DFAD 

•  POLYTHIN  -  cull  points  in  a  line  file  maintaining  requested  accuracy 

•  POLYTRI  -  triangulate  a  point  data  set  for  surface  fitting 

•  POLYSCRB  -  scribe  a  polyfile  into  an  image 

TABLE  PROCESSING  ROUTINES 

Tables  are  simple  flat  files  of  up  to  a  hundred  columns  and  200000  records. 

Columns  can  contain  character  (variable  length),  short  integer,  integer,  floating  point,  or 
double  precision  data.  The  file  contains  a  data  dictionary.  These  routines  constitute  a 
complete  data  management  capability  for  engineering  type  applications.  Typically,  the 
records  trace  the  path  of  an  aircraft,  so  it  is  strongly  desired  to  use  the  sequence  of  records 
in  most  of  the  calculations.  Also,  the  arithmetic  capabilities  are  heavily  used.  These 
characteristics  of  engineering  applications  rule  out  the  use  of  a  relational  system;  however, 
the  convenience  of  a  relational  system  is  kept  available  by  two  routines  that  transfer  a  table 
to  the  Ingres  (c)  relational  database  system  used  at  RAND.  Because  of  the  limited 
functionality  of  this  system  and  because  of  the  TAE  interface,  this  system  is  very  fast  and 
very  easy  to  use. 

•  DEFTABLE  -  define  a  table  and  its  field  formats 

•  ACOPIN  -  create  a  table  from  external  data  in  character  format 
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•  ICOPIN  -  create  a  table  from  an  Ingres  (c)  table 

•  ACOPOUT  -  write  selected  parts  of  a  table  to  character  format 

•  ICOPOUT  -  write  selected  parts  of  a  table  to  an  Ingres  table 

•  REPORT  -  print  selected  parts  of  a  table  with  headings 

•  SORT  -  sort  a  table 

•  RETRIEVE  -  retrieve  a  new  table  from  a  table 

•  ARITH  -  apply  an  arithmetic  function  to  rows  or  columns  of  a  table 

•  JOIN  -  join  values  from  a  secondary  table  into  a  table  using  keys 

•  JOIN2  -  join  two  tables  horizontally,  vertically,  or  cross-product 

•  AGGRG  -  aggregate  columns  of  a  table  according  to  a  control  column 

•  AGGRG2  -  aggregate  and  collapse  the  table  vertically 

•  PPLOS  -  compute  line  of  sight  in  terrain  data  into  a  table.  The  table  contains  the  desired 
map  coordinates  and  elevations. 

PROJECT  SPECIFIC  APPLICATION  ROUTINES 

The  STP  system  and  the  TAE  provide  an  excellent  environment  for  the  development 
of  application  routines.  Because  a  user  interface,  system  services,  documentation  aids,  and 
other  data  handling  routines  are  already  in  place,  the  programmer  can  usually  concentrate 
on  the  increments  of  technology  needed  for  his  application.  Even  faster  development 
occurs  when  tasks  can  be  performed  by  a  procedure  —  a  combination  of  the  standard  routines 
above.  Procedures  benefit  from  decreased  debugging  time  since  the  standard  routines  are 
debugged  by  heavy  use  in  multiple  projects.  Only  the  LHX  project  routines  and  procedures 
are  listed  here.  Of  the  routines  below,  only  FP  is  a  program,  the  others  are  user-defined 
procedures. 

•  FP  -  trace  a  flight  path  in  position,  elevation,  and  velocity  through  a  map-like  color 
graphics  display  of  terrain  and  culture.  A  flight  dynamics  routine,  HELCOM,  checks  for 
path  feasibility  and  a  magnifier  window  checks  for  ground  clearance.  Radars  or  other 
sensors  and  their  areas  of  visibility  can  be  displayed. 

•  LHXELV  -  prepare  an  elevation  data  set  combining  DMA  DTED  terrain  data  and  DMA 
DFAD  culture  data  (these  data  sets  are  described  in  Sec.  II).  The  user  can  specify  a 
formula  to  give  random  variations  in  tree  density  and  height. 
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•  LHXFPPREP  -  prepare  the  color  graphic  map  utilizing  a  shading  technique  for  the 
elevation  data  and  color  overlays  for  the  culture. 

•  LHXW  -  calculate  window  exposure  for  a  flight  path,  a  terrain  data  set,  and  a  set  of 
defensive  sites 

•  LHXWREP  -  present  statistical  summaries  of  the  results  of  procedure  LHXW. 
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II.  STP  DATA  PREPARATION  PROCEDURES 


One  of  the  features  of  STP  is  the  rapid  conversion  of  standard  geographic  files  to  the 
internal  format  of  the  STP  analysis  modules.  This  allows  a  new  study  area  to  be  prepared 
from  scratch  in  about  one  day  so  long  as  the  standard  files  are  available.  The  standard  files 
used  in  this  study  were: 

1.  DMA  Digital  Terrain  Elevation  Data  (DTED)  -  These  data  are  produced  by  stereo 
photogrammetry  and  associated  data  operations  and  gives  terrain  elevation  at  a 
rectangular  grid  of  points  for  a  spacing  of  three  seconds  of  arc  in  latitude  and  three 
seconds  of  arc  in  longitude.  Above  SO  degrees  latitude,  the  longitudinal  spacing 
becomes  six  seconds  of  arc.  Thus,  the  spacing  usually  falls  between  90  and  120  meters 
per  spacing.  The  elevation  value  is  given  as  an  integer  and  is  in  meters  above  sea 
level.  More  information  on  the  sea  level  datum  and  horizontal  and  vertical  accuracy 
can  be  found  in  Ref.  2. 

2.  DMA  Digital  Feature  Analysis  Data  (DFAD)  -  These  data  are  produced  by 
digitization,  manual  or  line-following,  from  maps  and  aerial  photography.  Certain 
defined  land  cover  types  and  objects  are  given  as  points,  lines,  or  polygons.  The  points 
are  specified  in  latitude-longitude,  and  lines  and  polygons  are  specified  as  chain  codes 
of  latitude-longitude  points.  The  polygons  are  closed  by  repeating  the  first  point  as  a 
last  point  Polygons  inside  of  polygons  are  allowed,  and  the  land  cover  at  a  point  is 
determined  by  the  innermost  polygon  containing  it.  A  DFAD  file  will  have  a 
quadrilateral  as  its  outermost  polygon.  The  polygons  are  numbered  sequentially  and 
referenced  to  an  associated  table  giving  type  code  (which  are  numbers  giving  the  land 
cover  type,  as  defined  in  Ref.  2),  typical  height,  etc.  Thus,  for  an  area  of  trees,  one  can 
read  the  typical  height  out  of  the  associated  table.  Fig.  1  diagrams  the  DTED  and 
DFAD  data  sets  illustrating  their  fundamental  differences  in  computer  representation. 

3.  HELCOM  Flight  Capability  Tables  -  Given  aircraft  weight,  loading,  elevation  above 
sea  level,  and  other  parameters,  the  program  HELCOM2  will  output  tables  of 
acceleration  capabilities  at  10  knot  velocity  intervals.  These  can  then  be  used  to  derive 
standard  maneuvers  for  analysis.  For  STP,  the  identical  tables  are  used  for  derivation 
of  the  maneuvers  needed  to  piece  together  a  mission  flight  path  in  a  stepwise  fashion. 


-8- 


DTED  format 


Fig.  1 — Computer  structure  of  DTED  and  DFAD 

4.  Digitized  road  data  -  Road  data  produced  with  sufficient  accuracy  by  digitization  can 
be  overlaid  on  the  graphic  display  to  create  a  simplified  computer  graphics  equivalent 
of  a  map. 

Because  this  study  needs  to  compare  aircraft  in  low  flight  against  radar,  infrared,  and 
visual  defenses,  it  is  important  to  integrate  terrain  and  forest  for  an  accurate  depiction  of  the 
flight  path  and  an  accurate  calculation  of  intervisibility.  The  data  preparation  operations  are 
made  more  difficult  by  the  fact  that  DTED  is  an  image  raster  format  and  DFAD  is  a 
polygon  format,  as  shown  in  Fig.  1.  STP  proceeds  by  converting  the  DFAD  to  raster  format 
and  adding  it  to  the  DTED.  The  steps  in  this  process  are: 

1.  Convert  the  DTED  data  to  an  internal  STP  format  (an  image).  Use  image  mosaicking 
if  the  study  area  covers  parts  of  several  DTED  data  sets. 
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2.  Resample  a  subwindow  of  the  DTED  data  to  the  selected  pixel  analysis  size.  For  the 
Fulda  Gap,  the  pixel  size  was  25  meters,  making  the  20  km  x  20  km  area  an  800  x  800 
image  (20  km  /  .025  km). 

3.  Convert  the  DFAD  contours  to  an  internal  STP  format. 

4.  Perform  an  affine  transform  of  the  latitude-longitude  values  to  the  DTED  coordinates 
using  the  comer  points  to  define  the  transform. 

5.  Thin  the  DFAD  contours  by  replacing  nearly  collinear  lines  by  a  single  line  using  a 
tolerance  of  25  meters. 

6.  Scribe  the  DFAD  contours  into  an  800  x  800  image.  The  result,  if  viewed,  would 
appear  to  be  black  lines  outlining  culture  areas  on  a  white  background. 

7.  Fill  each  connected  white  area  with  a  unique  identifying  number.  A  subsequent  option 
in  this  step  is  to  erase  the  boundaries,  melting  them  at  random  into  their  neighbors. 

8.  A  table  of  point  identifications  or  seeds  is  built  from  the  polygon  file  giving  a 
coordinate  and  an  associated  fill  number  using  the  fill  image  to  look  up  points  just 
inside  of  each  line.  The  polygon  identifier  from  the  DFAD  file  is  placed  in  a  column. 

9.  A  voting  procedure  takes  the  majority  vote  of  DFAD  polygon  identifiers  for  each  fill 
number  to  associate  fill  numbers  with  DFAD  identifiers. 

10.  The  DFAD  table  is  converted  to  an  internal  STP  format  keeping  the  DFAD  identifier, 
the  DFAD  class  code,  and  the  height 

1 1 .  The  two  tables  are  joined  using  the  DFAD  identifier  as  a  matching  key.  Residual  areas 
are  given  the  code  for  bare  ground. 

The  intermediate  product  here  is  a  DFAD  fill  image  which  registers  to  the  DTED 

data,  and  a  table  that  tells  what  each  fill  number  is  and  how  high  it  is.  Next,  the  combined 

elevation  image  is  produced: 

12.  The  height  values  are  injected  into  the  fill  image  using  the  fill  number  column  to  look 
up  what  height  goes  into  what  pixel.  The  result  is  a  culture  height  image. 

13.  To  give  the  effect  of  random  tree  heights,  the  culture  height  image  has  the  formula  (.5 
+  .5  *  rand)  applied  to  each  pixel,  where  each  call  of  rand  produces  a  pseudorandom 
number  between  zero  and  one.  This  formula  can  be  changed  as  desired. 

14.  The  DTED  image  is  added  to  the  randomized  culture  image  to  produce  the  combined 
elevation  image. 
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Then,  a  display  graphic  (an  equivalent  of  a  map)  is  produced  for  use  in  the  flight  path 

planner  program: 

15.  The  DTED  image  is  shaded  by  a  simple  algorithm  that  places  the  solar  illumination  in 
the  southeast  directioa  Eight  levels  of  shade  are  produced. 

16.  The  DFAD  table  is  divided  into  bare  ground,  trees,  and  all  other  classes.  These  are 
turned  into  the  three  color  numbers  for  brown,  green  and  purple,  and  are  injected  into 
the  fill  image  using  the  same  operation  as  step  12. 

17.  Using  the  STP  image  arithmetic  module,  the  shade  is  combined  with  the  three  color 
map. 

18.  A  contour  algorithm  is  applied  to  the  DTED  elevation  image  to  produce  50  meter 
elevation  contours. 

19.  The  contours  are  added  to  the  color  graphic  image  as  white  lines. 

20.  Roads  are  processed  as  in  steps  4-6  and  added  to  the  color  graphic  image  as  black 
lines. 

The  HELCOM  tables  are  not  changed  as  a  preparation  step. 
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III.  STP  FLIGHT  PATH  GENERATION 


The  STP  flight  path  generator  (program  FP)  is  used  to  input  a  high  data  resolution 
flight  path  over  the  prepared  terrain  and  culture  data  sets,  allowing  the  operator  to  control 
direction,  elevation,  and  speed.  The  operator  uses  a  keyboard  to  set  numeric  values  and  a 
mouse  to  locate  each  segment  of  the  flight  over  the  color  graphic  display.  The  flight  path  is 
checked  by  the  HELCOM  model  so  that  it  conforms  to  a  realizable  path.  Two  aspects  of 
this  control  scheme  need  to  be  discussed. 

First,  the  specifying  of  the  elevation  will  cause  only  the  end  point  of  a  flight  segment 
to  be  set.  HELCOM  will  fly  a  straight  line  between  the  points  of  that  segment,  and  the 
actual  elevation  achieved  along  the  segment  will  vary  with  the  combined  terrain  and  culture 
under  the  path  (Fig.  2).  For  low  flight,  the  straight  line  path  will  often  intersect  a  hill  or  a 
tree  (Fig.  3).  In  this  case,  the  operator  will  see  the  “clobber”  in  a  small  magnifier  window 
that  is  provided  in  the  corner  of  the  graphics  screen.  The  operator  has  the  choice  of  erasing 
the  last  segment  (or  last  “n"  segments)  to  retry  a  different  path  or  allowing  the  clobber  if  it  is 
deemed  to  be  an  allowable  grazing  of  treetops.  This  latter  situation  occurs  in  a  flight  path 
that  is  simulating  a  weaving  path  at  the  level  of  the  treetops. 

Second,  HELCOM  operates  by  applying  the  tables  of  acceleration  capabilities  for 
the  segment  selected  by  the  operator  given  the  state  of  the  aircraft  at  the  start  of  the  segment 
and  the  mode  requested  by  the  operator.  The  modes  at  present  are  accelerate,  decelerate, 
fixed  speed,  dash,  and  pop-up.  For  example,  if  the  aircraft  is  flying  at  37  knots,  is  in  the 
accelerate  mode,  and  a  near-level  segment  of  2100  ft  is  input,  the  HELCOM  routine  will 
apply  the  level  flight  maximum  acceleration  with  a  starting  velocity  of  37  knots  and 
distance  of  2100  ft,  yielding  a  new  final  velocity.  If  peak  velocity  is  reached  along  the  way, 
the  aircraft  will  fly  the  remainder  at  the  peak  velocity.  At  present,  turn  restrictions, 
overshoot,  and  undershoot  are  not  implemented.  However,  examination  of  the  flight  paths  in 
light  of  project  requirements  did  not  indicate  a  problem  with  these  deficiencies. 

The  sequence  of  events  in  generating  a  flight  path  with  FP  is  as  follows: 

1 .  Start  the  program  and  name  the  data  sets  to  be  input  for  the  color  graphic  map, 
combined  elevation,  and  sensor  location.  See  Fig.  4  for  the  TAE  screen  used  for  input. 

2.  Display  sensor  patterns,  if  desired. 


Map  view 

Fig.  2 — Stepwise  input  of  flight  path 


Fig.  3 — Side  view  showing  collision  and  trees 
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3.  Display  a  previous  path,  if  desired. 

4.  Select  path  entry  option.  Enter  aircraft  choice  (presently  LHX  helicopter,  AH-60,  or 
LHX  tilt  rotor).  Enter  initial  elevation  above  ground,  general  elevation  of  area  above 
sea  level,  and  maximum  performance  factor  (Fig.  5). 

5.  With  the  mouse  and  cursor,  select  a  starting  location. 

6.  With  the  mouse  and  cursor,  select  the  end  of  the  first  segment.  Then  view  the  segment 
as  a  black  line  on  the  map  and  as  a  red  line  in  the  terrain  profile  magnifier.  If  the 
segment  is  not  wanted,  it  may  be  erased  with  the  “e”  on  the  keyboard.  Repeated 
strokes  of  the  “e”  erase  previous  segments.  Also  view  the  status  of  the  aircraft  speed, 
elapsed  time,  aircraft  and  ground  elevations,  etc.,  in  a  side  window  of  the  graphics 
screen. 

7.  Step  6  may  be  repeated.  If  a  change  of  mode  is  desired,  the  following  keys  are  used: 
f  -  set  fixed  speed,  d  -  decelerate,  r  -  remove  fixed  speed,  p  -  pop-up.  The  default 
mode  is  accelerate. 

8.  Select  path  save  option.  Enter  a  disk  file  name  to  hold  the  coordinate,  time,  velocity, 
and  elevation  information  for  the  path. 

The  flight  planner  has  evolved  during  1988  to  improve  its  operator  interface.  A 

demonstration  of  the  current  flight  planner  is  given  in  the  appendix. 
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IV.  STP  FLIGHT  PATH  REFINEMENT  AND  INTERVISIBILITY  ANALYSIS 


The  flight  paths  generated  by  the  procedure  outlined  in  Sec.  Ill  consist  of  the  points 
input  by  the  operator  with  a  few  additional  points  added  by  the  HELCOM  routine  to  indicate 
transitions  from  acceleration  to  steady  or  steady  to  deceleration.  Typically,  the  operator 
inputs  about  50  points  for  a  10  km  flight  path  using  25  meter  pixel  resolution.  This  means 
that  the  points  have  an  average  spacing  of  about  200  meters  (10  km  /  50  points).  The 
analysis  procedures  now  applied  to  the  paths  can  be  set  to  a  finer  mesh  to  give  an  accurate 
portrayal  of  intervisibility  from  defensive  sites  and  the  resulting  sequence  of  events.  The 
combined  elevation  image  is  retained  for  a  lookup  of  intervisibility  at  the  finer  mesh. 

The  flight  path  refinement  and  intervisibility  analysis  takes  place  in  a  large  table  that 
is  handled  by  the  data  management  modules  of  STP.  The  vertical  ordering  of  records 
corresponds  to  the  sequence  of  events  in  the  flight  path.  A  schematic  of  the  table  layout  is 
shown  in  Fig.  6.  The  block  labeled  flight  path  contains  the  (x,y,z,t)  of  the  flight  path.  This 
block  is  repeated  for  each  sensor  location.  Other  fields  contain  additional  information  such 
as  ground  elevation  under  the  helicopter  and  derived  information  such  as  intervisibility  of 
sensor  to  helicopter.  The  visibility  windows  are  contiguous  l’s  in  the  latter  column. 

The  path  refinement  phase  uses  the  following  steps: 

1.  A  table  of  defensive  site  locations  in  latitude-longitude  and  feet  above  ground  is  read 
into  a  small  table. 

2.  Additional  fields  containing  UTM  coordinates  arc  calculated. 

3.  Ground  elevation  is  obtained  from  the  combined  elevation  image  (remember  that  trees 
have  been  cleared  from  these  spots  in  the  data  preparation  phase). 

4.  Defensive  site  elevation  above  sea  level  is  calculated  by  adding  the  ground  height  and 
sensor  height. 

5.  The  aircraft  flight  path  is  interpolated  with  additional  points  by  adding  uniformly 
spaced  time  values  in  the  time  column  that  correspond  to  a  maximum  distance  between 
points  selected  by  the  operator  (typically  25  meters). 

6.  The  velocity  for  added  points  is  interpolated  according  to  the  time  column.  Time 
increments  are  put  into  a  new  column.  Distance  increments  are  calculated  as  velocity 
times  the  time  increment.  A  running  sum  is  taken  of  the  distance  increments.  The 
map  coordinates  for  added  points  are  interpolated  according  to  the  running  sum  of 
distance.  This  entire  calculation  gives  an  accurate  position  and  time  of  the  end  points 
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of  accelerations  and  decelerations  assuming  uniform  acceleration.  It  is  off  only 
slightly  for  the  actual  case  of  nonuniform  acceleration-deceleration,  but  this  is 
acceptable  since  the  operator  input  points  are  strictly  as  given  by  HELCOM.  A 
helicopter  path  sequence  number  is  added. 

7.  Additional  fields  containing  UTM  coordinates  of  the  flight  path  are  calculated. 

8.  The  ground  elevations  at  the  helicopter  path  points  are  looked  up  in  the  combined 
elevation  image.  At  the  user  input  points,  the  helicopter  elevation  above  sea  level  is 
calculated.  The  sea  level  elevation  is  then  linearly  interpolated  according  to  the  time 
columa  The  actual  helicopter  elevation  is  then  calculated  as  the  difference  between 
the  elevation  above  sea  level  of  the  helicopter  and  the  elevation  of  the  ground  above 
sea  level. 


Visibility 


Radar  1 
location 

Flig 

pat 

ht 

| 

0 

0 

0 

0 

0 

1 

1 

1 

l 

0 

0 

0 

Window 

d 

Radar  2 
location 

Flig 

pat 

rep 

ht 

h 

eated 

Fig.  6 — Table  layout  for  intervisibility  analysis 
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9.  For  analysis  purposes,  the  average  elevation  of  the  helicopter  over  the  entire  path  with 
respect  to  time  is  calculated. 

10.  The  defensive  site  location  and  the  helicopter  path  table  are  joined  by  cross-product.  A 
very  large  table  results,  with  the  helicopter  path  repeated  for  each  defensive  site  (Fig. 

6).  Each  line  of  the  table  has  a  single  pair  —  one  defensive  site  location  and  one 
helicopter  locatioa  About  30  fields  of  information  are  available  including  UTM 
location,  time,  elevations,  velocity,  etc. 

11.  The  PPLOS  (point-to-point  line  of  sight)  program  is  applied  to  the  table  and  the 
combined  elevation  image  to  provide  a  new  column  that  contains  a  zero  for  not  visible 
and  a  one  for  visible  according  to  interposing  terrain,  trees,  or  buildings  and  including 
the  effect  of  the  earth’s  curvature.  The  program  is  based  on  image  processing 
techniques  that  allow  it  to  operate  quickly  with  very  large  elevation  images  and  very 
large  tables  of  intervisibility  points.  The  image  here  was  800  x  800,  but  10000  x  10000 
can  be  handled.  The  Bresenham  algorithm  (Ref.  3)  is  used  to  step  from  the  helicopter 
point  to  the  defensive  site  in  the  pixels  of  the  elevation  image.  The  image  is  read  in 
consecutive  swaths  that  fill  the  working  memory  of  the  SUN  computer  without  paging. 
Then  all  of  the  point  pairs  are  stepped  through  the  current  swath  of  data. 

The  procedure  above  yields  a  table  that  can  be  used  for  analysis  of  the  line-of- 
sight  windows  (in  time  and  space)  presented  by  a  helicopter  path  to  a  set  of  defensive  sites 
or  for  a  more  detailed  analysis  of  particular  defensive  weapon  types.  The  procedure  for 
aggregating  the  windows  is  as  follows: 

1 .  Subtract  UTM  coordinates  in  north  and  east  directions  and  calculate  the  hypotenuse  to 
get  line  of  sight  distance. 

2.  For  contiguous  zeros  or  ones  in  the  visibility  column,  make  a  running  sum  of  the  time 
increments. 

3.  Aggregate  and  collapse  the  table  using  the  visibility  column  as  a  control  and  the 
defense  identification  as  a  secondary  control.  Thus,  for  each  break  in  the  control 
values,  a  new  group  of  records  is  defined  and  collapsed  into  one  record.  A  maxim  jm 
control  field  is  also  defined  for  the  running  sum  of  time  defined  in  step  2.  The  values 
kept  in  the  resulting  record  are  picked  from  the  same  input  record  that  had  the 
maximum  running  sum. 


- 19- 


The  result  is  a  small  file  with  one  record  for  each  window  of  geometric  visibility  or 
nonvisibility.  The  length  of  the  window  in  seconds  is  given,  and  its  distance  from  the 
defensive  site  is  also  given.  The  procedure  saves  these  data  in  a  systematic  fashion  for 
further  processing.  As  each  case  is  run,  a  three  letter  code  may  be  input  by  the  operator  for 
flights  and  for  defensive  site  data  sets.  The  three  letter  code  is  used  to  name  a  new  large 
table  for  the  collection  of  all  window  records.  Separate  files  can  also  be  kept  with 
filenames  that  are  automatically  generated  by  the  three  letter  code  and  other  parameters  of 
the  case. 
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V.  STP  WINDOW  ANALYSIS  TECHNIQUES 


The  large  collected  file  produced  by  the  intervisibility  algorithms  is  used  for  a  series 
of  steps  that  analyze  the  geometric  exposure  of  the  aircraft.  The  file  contains  a  field  called 
nominal  velocity  that  is  set  to  the  desired  velocity  for  fixed  velocity  runs.  For  these,  the 
helicopter  will  fly  at  the  desired  velocity  except  for  the  initial  accelerate,  the  final 
decelerate,  and  steep  hill  climbs  that  forbid  the  desired  speed.  For  variable  speed  runs,  the 
nominal  velocity  is  set  to  zero.  There  are  slight  variations  in  the  analysis  below  for  the  two 
types  of  velocity  settings.  The  procedure  begins  by  selecting  the  subset  of  windows  for  the 
desired  analysis. 

1.  Retrieve  all  windows  that  arc  visible  (deleting  the  nonvisible). 

2.  Optionally,  retrieve  windows  that  are  classified  as  being  over  flat  or  over  hilly  terrain. 
This  classification  procedure  uses  an  image  processing  operation  to  determine  flat  or 
hilly  and  point  lookup  to  fill  the  field  to  be  used  for  retrieval. 

The  result  is  a  base  file  for  statistics  and  plotting  which  is  copied  for  each  of  the  steps 

below. 

3.  Sort  the  base  file  by  aircraft  and  nominal  velocity.  Set  up  a  column  containing  all 
ones.  Then  aggregate  and  collapse  the  file  by  these  fields  summing  the  other  fields. 
The  column  of  ones  becomes  a  count  of  windows  for  each  aircraft  type  and  nominal 
speed.  For  variable  speed  cases,  the  actual  velocity  is  used  in  place  of  the  nominal 
velocity  with  rounding  to  the  nearest  5  knots  value  (a  procedure  hereafter  known  as 
“bucketing”).  These  statistics  are  then  reported  and  plotted. 

4.  Bucket  the  window  lengths.  Process  the  file  as  in  step  3  except  add  window  length 
buckets  to  the  two  sort  fields.  The  result  will  be  a  histogram  of  window  lengths  by 
aircraft  and  velocity. 

5.  Sort  the  base  file  by  aircraft,  path  number,  and  nominal  velocity.  Aggregate  and 
collapse  the  file  by  these  fields.  The  average  elevation  of  the  paths  can  then  be 
reported. 

6.  A  measure  of  the  lethality  of  a  window  can  be  defined  as  length  of  the  window  in 
seconds  divided  by  the  distance  of  the  window  from  the  defense  site  in  km.  These 
values  are  then  bucketed.  Step  4  is  repeated  using  lethality  instead  of  window  length. 
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7.  A  more  advanced  measure  of  the  lethality  of  the  window  is  based  on  deriving  for  a 
window  the  number  of  kill  opportunities  of  a  generic  missile  defense  weapon.  Assume 
that  the  generic  weapon  has  a  detection,  acquisition,  and  firing  sequence  delay  of  tg 
and  a  missile  flyout  velocity  of  vg.  Also,  assume  that  the  next  sequence  commences  at 
the  moment  the  missile  hits  the  aircraft  These  assumptions  downgrade  distant 
windows  because  the  flyout  time  is  longer,  and  they  upgrade  long  windows  because 
one  or  more  complete  sequences  can  fit  in  them.  They  are  also  calculated  based  on  the 
defense  locations  given  in  the  study  case.  This  new  lethality  metric  is  then  bucketed 
and  treated  as  in  step  6  or  step  4. 
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VI.  STP  ATTRITION  MODEL 


The  STP  Attrition  Model  was  developed  to  analyze  the  survivability  of  the  LHX 
SCAT  (aerial  scout-attack),  AH-64,  and  LHX  tilt  rotor  aircraft  against  the  ZSUX,  SA-13, 
SA-14,  and  SA-15  air  defense  systems  under  a  variety  of  missions. 

The  unaggregated  table  created  in  Sec.  IV,  steps  1  to  1 1 ,  from  a  mission  flight  path 
flown  over  micro-terrain  is  used  as  input  to  the  STP  Attrition  Model.  Each  entry  in  the  table 
has  the  simulation  time,  the  aircraft  coordinates,  the  defensive  site  coordinates,  and  a 
visibility  field.  The  choice  of  an  air  defense  system  is  an  input  to  the  model.  The  final 
output  of  the  model  is  an  attrition  rate  L  for  a  particular  mission  flight  path  that  is  then  used 
to  calculate  Poisson  statistics. 

A  low  speed  (60  knots)  and  a  high  speed  (120-180  knots)  head,  tail,  flank,  and  bottom 
radar  cross  section  or  infrared  signature  for  each  aircraft/air  defense  combination  are  inputs 
to  processing  the  variable  speed  flight  path  through  the  detection  algorithm.  For  hits  and 
kills  the  data  required  for  each  weapon  system  include  missile  velocity,  and  the  target  and 
vulnerable  areas  (head,  tail,  flank,  top,  and  bottom)  of  the  aircraft  against  the  weapon 
system.  If  a  proximity  kill  weapon  system  is  under  consideration,  the  circular  error  probable 
and  number  of  shots  are  also  needed.  The  data  input  to  the  model  were  extracted  from 
Army  Materiel  Systems  Analysis  Agency  (AMSAA)  data. 

The  STP  Attrition  Model  algorithm  can  be  broken  down  into  six  major  steps:  STP 
flight  path  refinement,  calculation  of  break  lock-on  probability,  calculation  of  detection 
probability,  calculation  of  hit  probability,  calculation  of  kill  probability,  and  generation  of 
statistics.  A  more  detailed  description  follows. 

1.  As  described  in  previous  sections,  interactively  generate  the  candidate  flight  paths 
using  the  flight  planner.  The  flight  path  generated  incorporates  the  aircraft  flight 
dynamics  and  terrain  to  minimize  exposure  to  threat  weapons.  Execute  STP  flight  path 
refinement  procedure  to  obtain  instances  of  clear  line  of  sight  (CLOS)  between  the 
aircraft  and  threat  site. 

2.  Obtain  break  lock-on  probability.  The  time  duration  under  a  visibility  window  is  used 
as  an  index  into  a  table  of  break  lock-on  probabilities. 

3.  Calculate  detection  probability  for  each  LOS  window.  First  determine  the  direction 
and  position  of  the  target  with  respect  to  the  sensor.  Calculate  sensor  coordinates  in 
new  coordinate  system  (L,  M,  N)  from  coordinates  (x,  y,  z).  Select  the  appropriate 
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radar  cross  section  or  infrared  signature  based  on  weapon  system  and  aircraft  velocity. 
The  following  substeps  calculate  a  composite  signature  based  on  the  type  of  sensor 
used  in  the  weapon  system.  If  the  weapon  system  uses  a  radar  sensor  (ZSUX,  SA-1S), 
then  the  following  substeps  are  followed.  Given  the  radar  cross  sections  of  the  target 
for  normal  and  Doppler  radar,  calculate  the  radar  cross  section  constants  based  on  the 
spatial  orientation  of  the  target  to  the  radar.  Use  the  constants  to  solve  for  the  signal- 
to-noise  and  signal-to-clutter  values  for  both  normal  and  Doppler  radar  and  choose  the 
best  signal.  Otherwise  the  weapon  system  uses  an  infrared  sensor  (SA-13,  SA-14). 
Given  the  infrared  signatures  of  the  target,  calculate  the  infrared  signal-to-noise  ratio 
based  on  the  spatial  orientation  of  the  target  to  the  sensor.  The  resulting  radar  or 
infrared  signal  is  then  used  as  an  index  into  a  table  of  detection  probabilities. 

4.  Calculate  hit  probability.  Eliminate  the  LOS  windows  that  do  not  have  at  least  one 
entry  that  meets  the  detection  threshold.  For  each  remaining  LOS  window,  take  the 
earliest  time  of  detection  offset  by  the  missile  firing  sequence  to  obtain  time  of  missile 
fire.  Match  up  missile  flyout  time  —  the  range  between  target  and  sensor  divided  by 
missile  velocity  —  against  the  length  of  time  visible  since  detection  and  register  a  hit  if 
the  missile  arrives  at  the  target  within  the  LOS  window. 

5.  Calculate  kill  probability.  For  each  visibility  window,  take  the  earliest  time  a  hit  is 
registered.  Based  on  projected  target  areas,  projected  vulnerable  areas,  the  spatial 
orientation  of  the  target,  and  whether  the  weapon  system  uses  a  direct  or  proximity 
missile,  calculate  the  kill  given  hit  probability. 

6.  Calculate  the  aircraft  attrition  rate  for  the  mission.  For  each  aircraft,  compute  an 
attrition  metric  from  individual  kill  probabilities  and  convert  probabilities  to  a  Poisson 
measure  of  the  attrition  rate  for  the  flight  path. 
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VII.  FUTURE  DEVELOPMENT 


The  LHX  project  has  fostered  the  development  of  a  complex  set  of  interrelated  tools 
(the  SIP  or  SUN  Terrain  Procedures)  to  analyze  aircraft  flight  over  terrain  with  defenses. 

An  effort  to  generalize  this  work  for  multiple  project  use  and  the  support  of  models  in 
addition  to  JANUS  is  now  under  way.  The  three  most  fundamental  categories  of  tools  are: 
geographic  information  systems,  interactive  graphics,  and  analysis  procedures.  Fig.  7  shows 
how  these  categories  of  tools  will  provide  multiple  project  support  from  a  single  software 
base  system.  The  new  software  system  is  called  Cartographic  Analysis  and  Geographic 
Information  System  (CAGIS).  Cost  savings  and  increased  capability  will  derive  from  the 
following: 

1.  The  CAGIS  system  contains  general  purpose  program  modules  that  are  reused  in  many 
projects. 

2.  The  CAGIS  modules  are  under  change  control  in  a  system  library,  hence  are  more 
reliable  than  custom  software. 

3.  The  custom  analysis  procedures  are  analyst-written  procedures  using  CAGIS  modules. 

4.  Custom  graphics  programming  (which  is  notoriously  difficult)  is  reduced  in  difficulty 
by  the  supporting  CAGIS  and  analysis  capabilities. 
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Fig.  7 — Multiple  project  support  with  CAGIS 


-27- 


Appendix 

A  FLIGHT  PLANNER  DEMONSTRATION 


This  interactive  demonstration  uses  a  modernized  version  of  the  software  used  in  the 
LHX  project.  The  following  instructions  detail  the  setup  actions  and  the  many  “point- 
push”  actions  to  manipulate  the  image,  paths,  and  patterns.  MOVE  is  short  for  move  the 
mouse,  RIGHT  is  short  for  press  the  right  side  button  on  the  mouse.  Similarly,  MIDDLE  and 
LEFT  are  button  actions.  SELECT  is  short  for  while  holding  the  button  down  move  the 
mouse  until  the  screen  arrow  is  within  the  area  of  the  labelled  screen  menu  selected  and 
release  the  button.  SHIFT  is  short  for  press  the  shift  key  on  the  keyboard.  Logon  on  a  Color 
SUN  Workstation.  Then  change  directory  by: 
cd  /s/app/app 

If  suntools  windows  appear  automatically,  exit  the  suntools  and  reenter  suntools  as  follows: 

suntools  -s  .suntools 
To  setup  the  CAGIS  commands,  enter: 

source  log 

To  run  the  demonstration  type: 

cagls 

Wait  until  the  CAGIS  prompt  appears  (about  30  seconds).  Proceed  to  the  next  page  and 
demonstrate  the  various  Flight  Planner  actions.  When  the  demonstration  is  complete, 
proceed  with  the  following  actions  to  exit  the  Flight  Planner.  To  remove  a  window: 

MOVE  to  the  banner  at  the  top  of  the  window  and  RIGHT  and  SELECT  Done. 

The  window  will  disappear.  When  all  the  windows  have  disappeared  the  cursor  returns  to 
the  CAGIS  prompt.  Then  type: 
exit 

To  quit  the  Right  Planner  demonstration: 

MOVE  to  the  image  window  and  RIGHT. 

A  pop-up  menu  will  appear. 

SELECT  quit. 

All  windows  will  disappear  and  CAGIS  will  exit. 


Fig.  A. ^-Flight  Planner  image  window  (normally  in  color) 

Running  the  Flight  Planner  Demo 
At  the  CAGIS  prompt  type: 

t  ftp 

The  Flight  Plan  Routine  window  will  appear.  Now  take  the  following  actions: 

MOVE  to  RESTORE  and  LEFT. 

The  Restore  Tutor  Parameters  window  will  appear,  then 

MOVE  to  Parameter  File  Name  and  type:  ftp  MOVE  to  OK  and  LEFT. 
The  Flight  Plan  Routine  window  will  fill  with  parameters  and  BEEP. 

MOVE  to  RUN  and  LEFT. 

Next  the  Right  Path  Parameters  window  will  appear. 
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MOVE  to  RESTORE  and  LEFT. 

The  Restore  Tutor  Parameters  window  will  appear,  then 

MOVE  to  Parameter  File  Name  and  type:  fdy  MOVE  to  OK  and  LEFT. 

The  Flight  Path  Parameters  window  will  fill  with  parameters  and  BEEP. 

MOVE  to  RUN  and  LEFT. 

The  Flight  Path  Parameters  window  will  disappear  and  a  large  image  window  will  appear. 
After  about  30  seconds  a  small  black  rectangle  will  appear  in  the  upper  left  comer.  It  will 
slowly,  line-by-line,  turn  white.  This  will  take  several  minutes.  When  this  process  is 
complete  the  entire  image  window  will  fill  with  the  terrain  data  in  color  including  forest, 
rivers  cities,  boundaries,  etc.  See  Fig.  A.l. 


Fig.  A.2 — Plotting  of  a  flight  path  (with  side  view) 

Plotting  a  Flight  Path 

To  create  a  path  across  the  terrain  in  the  image  window,  take  the  following  actions: 
MOVE  to  the  image  window  and  RIGHT. 

A  pop-up  menu  will  appear. 

SELECT  Edit  Path  and  MOVE  to  the  arrow  on  the  line  following  Edit  Path. 

A  second  menu  will  pop-up. 

SELECT  New  Path. 

You  are  now  in  the  path  creation  mode.  To  create  a  flight  path: 

MOVE  to  any  point  you  choose  and  LEFT. 

A  flight  path  point  will  be  drawn. 
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Then  MOVE  to  any  second  point  and  LEFT  again. 

A  second  point  will  be  drawn  and  a  side-view  window  will  appear  showing  the  flight 
altitude  and  the  terrain  traversed.  Sec  Fig.  A.2.  Repeat  this  action  until  the  flight  path  is 
complete. 

MOVE  to  the  image  window  and  LEFT  and  SELECT  Path  and  MOVE  to  the  arrow  on 
the  line  following  Path  and  SELECT  Sava  Path  in  the  second  pop-up  menu. 

The  Pathtools  Dynamic  Parameters  window  will  appear. 

Enter  the  filename  for  the  path  and  MOVE  to  RUN  and  LEFT. 

This  will  save  the  flight  path  parameters  for  future  uses. 


Fig.  A.3 — Flight  path  creation  menu 


Flight  Path  Creation 

To  modify  a  flight  path: 

MOVE  to  the  image  window  and  RIGHT. 

A  pop-up  menu  will  appear. 

SELECT  Edit  Path  and  MOVE  to  the  arrow  on  the  line  following  Edit  Path. 
The  a  second  menu  will  pop-up. 

SELECT  the  command  you  want. 

Your  choices  are  (see  Fig.  A.3): 

New  Path  to  begin  a  new  path. 

Add  Point  to  add  mote  points  to  a  path. 
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insert  Point  to  place  a  point  between  two  points. 
Delete  Point  to  remove  a  point. 

Move  Point  to  hook  a  point  and  move  it. 

Select  Path  to  change  paths. 

Get  Info  to  provide  more  information  about  a  point. 


Fig.  A  A — Flight  Planner  magnifier  and  wire  diagram 
Flight  Planner  Magnifier 

To  magnify  the  any  location  (by  three  times  magnification): 
MIDDLE  to  magnify  the  current  point. 

Additional  information  is  displayed  beneath  the  magnified  image 
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To  create  a  wire  diagram  window  (three  dimensional)  for  the  terrain  about  a  point: 

SHIFT  and  MIDDLE  at  the  current  point. 

To  change  the  wire  diagram  window: 

RIGHT  within  the  wire  diagram  window  for  a  pop-up  menu  of  changes. 

To  change  the  color  of  a  path: 

RIGHT  on  any  point  and  SELECT  Pen  Color.  SELECT  color. 

To  change  the  image  shading: 

SHIFT  and  the  letter  s 

The  shading  of  the  image  will  alternate  with  the  light  coming  from  either  the  upper  left  or 
the  lower  right. 

SHIFT  and  the  letter  g 

The  shading  of  the  image  will  alternate  with  gray  or  normal  coloring.  See  Fig.  A.4. 


Fig.  A.5 — Flight  Planner  radar  pattern  generation 


Flight  Planner  Radar  Pattern  Generation 

To  plot  a  radar  pattern  from  a  previously  chosen  radar: 
MOVE  to  the  image  window  and  RIGHT. 

A  pop-up  menu  will  appear. 

SELECT  Radar  and  MOVE  to  the  arrow  on  the  Radar  line. 

A  second  menu  will  pop-up. 

SELECT  Load  Radar  Pattern. 

A  radar  pattern  window  will  appear: 

MOVE  to  RESTORE  and  LEFT. 

The  Restore  Tutor  Parameters  window  will  appear,  then 
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MOVE  to  Pirnmfc  FU«  Mama  and  type:  ftp  MOVE  to  OK  and  LEFT. 

The  radar  pattern  window  will  fill  with  parameters  and  BEEP.  MOVE  to  RUN  and  LEFT. 
See  Fig.  AJ. 
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